Every servo axis on your line has been telling you it’s about to cause a quality problem for years. Following error creeping up before a bearing fails. Torque saturation on a press axis that correlates suspiciously well with the scrap spike three shifts later. Jerk limit violations that show up right before a mechanical coupling starts working loose. The data has always existed inside the drive. The problem was never data availability — it was that getting it out meant a vendor-specific driver, a custom OPC tag map built by hand, or an integrator writing a one-off bridge that nobody else on the plant floor could maintain after they left.
That’s changed, and it’s changed quietly enough that a lot of plant floors haven’t noticed yet. Siemens TIA Portal, Beckhoff TwinCAT, and Rockwell Studio 5000 have all converged on shipping PLCopen-standard motion function blocks alongside OPC UA companion specification support for drive and axis diagnostics. That combination — a standardized function block interface on the PLC side, paired with a standardized information model on the OPC UA server side — is the first time cross-platform motion diagnostics has been a practical, buildable thing rather than a slide in a standards-body deck.
What actually changed here
PLCopen’s motion control function blocks (the MC_MoveAbsolute, MC_Power, MC_ReadAxisError family, and related blocks) have been a stable standard for well over a decade — that part isn’t new. What’s new is that the axis state those function blocks operate on is now consistently exposed through OPC UA using the companion specifications built for motion and drive technology, rather than through each vendor’s proprietary tag namespace. Following error, actual torque, torque limit status, velocity, and axis state machine position are modeled as OPC UA nodes with consistent semantics, not just consistent names.
That distinction matters more than it sounds like it should. A tag called “FollowingError” that means something different on three different platforms is worse than no standard at all, because it invites your SCADA integration to be quietly wrong. A companion spec that defines the engineering units, the update semantics, and the relationship between that value and the axis state machine gives you something you can actually build alarms and analytics logic on top of, once, and reuse across machine types and vendors.
Why SCADA and MES have historically ignored this data
Most SCADA historians and MES quality modules today are still fed from a narrow slice of the PLC — cycle counts, part presence, a handful of process interlocks, maybe a fault code. Axis-level diagnostics rarely make the cut, not because anyone decided servo health wasn’t valuable, but because pulling it out required either a custom driver per drive vendor or manual OPC tag configuration that didn’t survive the next machine rebuild. Integrators priced it as a nice-to-have add-on because it was genuinely expensive to build and brittle to maintain. The OPC UA companion spec approach removes the vendor-driver dependency; it doesn’t remove the need to actually map the data correctly.
Where the mapping actually happens — and where it goes wrong
The failure mode integrators need to plan for isn’t “the data isn’t there.” It’s there. The failure mode is treating the axis object as a black box you point a generic OPC UA client at and hope for the best. Three things need deliberate attention at commissioning:
- Axis state context, not raw values. A following error value means something completely different during acceleration than it does in steady-state motion. If you pull the raw tag into SCADA without also mapping the axis state machine (accelerating, constant velocity, decelerating, standstill), your alarm thresholds will either nuisance-trip constantly or miss the excursions that matter. The companion specs expose state machine data specifically so you can gate diagnostics by motion phase — skipping that step is the single most common commissioning shortcut that produces useless alarms.
- Sampling rate versus historian cadence. Torque saturation and jerk limit events happen on millisecond timescales. Most plant historians are configured for second-or-slower polling because that’s what process tags need. If you wire axis diagnostics into the historian at the same cadence as your tank levels and flow rates, you’ll miss every transient event that actually predicts mechanical wear — you’ll only catch the sustained faults that would have tripped a fault code anyway. Event-based or condition-triggered subscription, not blanket polling, is what makes this data useful.
- Unit and scaling consistency across axis types. A companion spec defines that torque is expressed as a percentage of rated torque, or as an engineering unit — but if your commissioning team doesn’t verify that mapping matches across a rotary axis on one machine and a linear axis on another, you’ll build quality correlations on data that isn’t actually comparable. This is the mapping error that’s hardest to catch after the fact, because everything still looks like a valid number.
What breaks when you skip it
The practical cost of treating this as “just point OPC UA at the drive and go” shows up in two places. First, alarms fire too late — because a threshold set on raw following error without state-machine context either doesn’t trip until the fault code does anyway, defeating the purpose, or trips so often during normal accel/decel that operators disable it within a month. Second, and more costly, you lose the correlation between mechanical wear and quality drift entirely. The whole point of pulling torque saturation and jerk data into MES is to connect gradual servo degradation to gradual dimensional or surface-finish drift before it becomes scrap. If the diagnostic tags are sitting in the historian at the wrong cadence or without state context, that correlation analysis has garbage inputs, and nobody trusts the dashboard built on top of it.
The practical takeaway for integration teams
Treat the axis data model mapping as its own commissioning deliverable, not a checkbox inside the motion commissioning task. Document which OPC UA nodes map to which axis states, set historian or MES ingestion cadence based on the failure modes you’re actually trying to catch, and validate unit consistency across every axis type on the line before you build a single SCADA alarm on top of it. Do that work once, correctly, and the standardization Siemens, Beckhoff, and Rockwell have converged on actually pays off — you get a reusable, vendor-agnostic diagnostic tag set instead of another integration project that only the original systems integrator understands. Skip it, and you’ve just built a more expensive version of the black box you had before.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
